---
title: Objectives & Architecture
---

Welcome to the **Blok** framework! This document provides an overview of the project's objectives and architecture to help contributors understand its purpose and structure.

---

## **Why We Are Building Blok **  

Modern software architectures have evolved from monoliths to microservices, and now to nanoservices. While microservices introduced modularity and scalability, they also created **significant maintenance overhead**, **code duplication**, and **complex dependency management**.  

Blok is built to **solve these challenges** by **maximizing code reusability and simplifying service management**, while offering the flexibility to deploy applications in **any architecture**—whether nanoservices, microservices, or monoliths.  

---

### **Problems with Microservices**  
Microservices separate logic based on **business objectives** rather than **functional reusability**, leading to:  
- 🚨 **Massive Code Duplication** – Similar functionalities (e.g., authentication, logging, database access) are implemented repeatedly across services.  
- 🔄 **High Maintenance Overhead** – Updating shared logic across multiple services requires significant effort and coordination.  
- 🏗 **Operational Complexity** – Managing multiple independent services introduces deployment, scaling, and observability challenges.  

While microservices solve some **scalability** problems, they introduce **architectural inefficiencies** that bloks can address.  

---

### **Our Approach: Nanoservices with Deployment Flexibility**  
We focus on the **architectural benefits** of bloks while ensuring that teams can **deploy applications in any model**—not just as nanoservices.  

#### **Key Design Principles**  
✅ **Code Reusability** – Nodes (nanoservices) are designed as reusable, independent execution units.  
✅ **Built-in Monitoring & Observability** – Every nanoservice is containerized, automatically monitored, and resource-optimized.  
✅ **Workflow-Driven Development** – Instead of writing services from scratch, developers **compose workflows using nanoservices**, reducing redundancy.  

#### **Deployment Flexibility**  
With Blok , developers can **build with nanoservices** but deploy in different architectures:  
🔹 **Blok** – Fully isolated, event-driven services for maximum modularity.  
🔹 **Micro** – Deploy a group of bloks together as a single microservice.  
🔹 **Monolith** – Bundle all bloks into a single executable for easier management.  

**Our goal:** Enable teams to **leverage nanoservice benefits** without enforcing a single deployment approach.  

---

### **Conclusion**  
Blok is designed to give **developers control** over how they build and deploy applications. Instead of being forced into a microservices-only approach, teams can:  
- ✅ **Reuse code efficiently**  
- ✅ **Reduce maintenance overhead**  
- ✅ **Choose their preferred deployment model**  

We believe **architecture should serve developers, not dictate constraints**—and that's why we're building Blok . 🚀

## **Objectives**
The primary goal of `Blok` is to provide a **scalable, modular, and efficient nanoservice-based framework** for building cloud-native workflows. It enables developers to create **isolated, reusable, and dynamically scalable** execution units with minimal operational overhead.

### **Core Objectives**
1. **Extreme Modularity**  
   - Nodes (nanoservices) are independent, reusable components.
   - Designed to be lightweight and purpose-driven.  

2. **Optimized Resource Utilization**  
   - Dynamic resource allocation to scale workloads efficiently.
   - Containerized execution to ensure security and isolation.

3. **Workflow Automation**  
   - Nodes are orchestrated in structured workflows.
   - Support for sequential, parallel, and conditional execution.

4. **Ease of Development & Contribution**  
   - Clear and structured approach to building and sharing nodes.
   - Support for multiple runtimes (e.g., TypeScript, Python).
   - Community-driven ecosystem for open-source collaboration.

---

## **Project Structure**
The `Blok` framework follows a **nanoservice architecture**, where each node is a self-contained execution unit with its own runtime and lifecycle.

### Core directories and components:

1. **`/docs`** – project documentation and guides.
2. **`/core`** – core application components, including [runner](/docs/c/core/runner) and [shared](/docs/c/core/shared).
3. **`/infra`** – monitoring & observability components, and Docker configurations. For more details, see [here](/docs/d/advanced/monitoring-obserbvability).
4. **`/nodes`** – a collection of built-in nodes for common use cases. View full list [here](/docs/d/core-concepts/nodes-built-in).
5. **`/packages`** – `npx`-based CLI. For full list of commands, see [here](/docs/d/core-concepts/nanoctl).
6. **`/templates`** – list of templates available for use via CLI.
7. **`/workflows`** – sample workflows and configurations. For more details, see [here](/docs/d/core-concepts/workflows).
8. **`/triggers`** – list of triggers available for use via CLI. For more details, see [here](/docs/d/core-concepts/trigger).